Stacks, display Modes, takeovers, and moving widgets between tabs - #378

@jasonstantler drap and drop to tab has some hitches:

Test 1

1. I created a stack and added a new tab
2. I enabled layout edit and then dragged to the tab I just created and the stack's edit window is stuck on the screen and requires a page refresh to fix it.

Test 2

1. I purposefully did not create a new tab and edited the layout
2. I dragged a widget to the "+" to create a new tab which crashed the app

Stacks seem to work well.
Haven't tried modes but it sounds neat. I think if we can tighten up drag and drop we can merge it in.

@jasonstantler still a little buggy:

1. When I dragged the calendar to the bar to create a tab, it prompted, I created and it moved, as as expected, but during the same layout edit session I also moved two widgets on the home screen and repositioned them. Went back to the newly created tab to confirm that position looked good, and it did, so I saved the layout. I went back to the home tab the moved widgets went back to their old positions. Before modifying positions and saving again I just refreshed the page and they adopted the positions I had moved them to during the first layout edit, as expected, so the data is being saved and on refresh adopts the position, it just doesn't show the new positions unless the page is refreshed. That could be a data/timing issue or a purely client side issue because on refresh things were they should have been. If we can get that sorted then I'll merge.
2. Stacks seem to be working great.

@jasonstantler when this is good, have claude rebase so the conflicts are resolved and then we can get it in.

This is a neat addition!

A few issues that came up on a "take a quick look at this PR" on Claude.

1. Stacking deletes the members' tab entries. stackWidgets (and placeOn in StacksSettings) delete ${tab}::<widget>, but that entry holds more than position: Weather's location, unit and layout, Calendar's view mode and week start. Inside the Stack, Weather falls back to defaults, and saving its settings again 404s ("Assignment not found") because the entry is gone. Unstacking posts fresh entries with null layout, so the settings are lost for good, with no undo.

2. Ordinary Move/Resize drags now carry or stack by accident. Releasing in the bottom rows near the dock moves the widget to the nearest tab (pickDockTarget), resting within EDGE_PX of a screen edge for CARRY_DWELL_MS switches tabs with the widget in hand, and resting over another widget for 550ms makes a Stack on release. Placing a widget in the first or last column or the bottom row hits these easily.

3. droppedAwayRef can stay set and drop the next save. With collisions prevented, a drag onto another widget (or onto a dock tab with the cell underneath taken) never moves, so onLayoutChange never fires and the flag is only cleared by the next saveLayoutsToApi. That next real rearrangement is discarded and snaps back on reload.

4. Rolling back hides stacked widgets. Members are removed from config_json and only stack:<id> plus widgetStacks record them, so any build without this PR shows none of them while they stay enabled.

5. A late alarm turns a mode on for up to 12 hours. alarmWindow wraps to the next until when the alarm rings after it (Morning until 09:00, alarm at 09:30, on until 21:30), and automaticModeAt checks alarms before schedules, so an evening alarm overrides Night. A ring after until should open no window.

Also worth a look:

• One failed HA poll in useDisplayModes sets states: {}, and stepRules forgets every rule, so dismissed takeovers come back and urgent ones wake and chime again.
• Repeated attention('urgent') renews at each call, so it chimes every time and the dismissal never sticks.
• The HA polls run on a plain setInterval with no in-flight guard, and errors aren't cached, so requests pile up while HA is down.

For the rebase onto #375: the new writers (moveWidgetToTab, stackWidgets, unstackOnTab, confirmRemoveWidget, undoRemoveWidget) capture API_DEVICE_URL at render time across awaits, so they should resolve the device at call time the way fetchWidgetAssignments now does. onLayoutsSaved running before the PATCH lands would also drop the touched ids early in reconcileLayoutWithLive and reopen the snap-back that #375 fixed.

@jasonstantler Thanks, this is close. On the latest head (12b25f5), server tests (745), client tests (1018), check:i18n and the build all pass. In Edge, against a real server:

• The snap-back from my second comment is fixed: two widgets moved on Home, a visit to the new tab and Save, then back to Home leaves them where they were moved. The server and a reload agree.
• Dropping a widget on + opens the new-tab dialog and moves it into the new tab, with no errors.
• A drop just above the dock stays on its tab. A Stack keeps its widgets' entries (marked in_stack), and when it's on screen at page load it moves to another tab with them.

Two things need fixing before merge:

1. A Stack made by holding one widget on another breaks the page until a refresh. This is my Test 1 from the first comment. Steps:

1. In Move/Resize, hold Photos on Chores (or Photos on Calendar) until "Stack with…" shows, then let go.
2. The console logs "Maximum update depth exceeded", and it keeps happening (1, then 3, then 9 errors over a few seconds).
3. The Stack grows on screen (405px wide, then 607px, then 1102px, at an x that doesn't line up with the grid), and a widget card is left floating over its neighbour.
4. Add a tab with + and drag the Stack onto it in the dock. Nothing happens and no request is sent. Sometimes a tap no longer selects the Stack at all.

After a refresh, the same Stack selects, drags to the other tab and takes its widgets along, with no errors. So the trouble is in the session where the Stack was made. The loop shows up in Chores' useEdgeFade ResizeObserver, but that's only where React notices it: the widget keeps re-rendering because the grid around it keeps changing size. My guess is the grid's own layout still has the dragged widget at its last drag position after it went into the Stack, and that fights the new widgets list. Worth checking alongside droppedAwayRef.

2. The display-mode Home Assistant routes can write to any input_select in Home Assistant, with no PIN. The server doesn't check the admin PIN on these routes, and plugin frames can't reach them, but any browser on the network can:

• POST /api/devices/<any>/modes/ha/helper with { "entity_id": "input_select.<anything>" } runs set_options on that helper, replacing its options with Automatic/Normal/the modes;
• PATCH /api/devices/<name>/settings can set displayModes.ha.helper (or helperId) to any helper. After that, /modes/ha/sync rewrites its options and /modes/ha/select sets its state.

An input_select often drives household automations (house mode, alarm mode), so this lets a kid's tablet change them. HomeGlow's other Home Assistant writes go through each plugin's scoped access, and unlocking or disarming needs the PIN. Suggested fix:

• Make displayModes.ha server-owned: the settings PATCH keeps the stored ha.helper/helperId and ignores incoming values.
• Have /modes/ha/helper check the admin PIN the way /api/plugin/v1/ha/:pluginId/action does: checkAdminPin, unless the display remembers it.
• Also, /modes/ha/helper calls writeDevice → ensureDeviceExists, so it creates a device row for an unknown name. Return 404 instead, as the viewport route from feat(mirror): remote-control mirror mode to configure another display #375 does.

The sensor that /report posts to is limited to sensor.homeglow_*_showing, which is fine.

Small and unrelated: under npm run dev, react-grid-layout's prebundled react-draggable reads process.env.DRAGGABLE_DEBUG, so any drag throws "process is not defined" in the dev server. Production builds are fine. This happens on main as well, not because of this PR.

Stacks and the Move/Resize changes otherwise look good. Once 1 and 2 are fixed, I'll recheck and merge.

🤖 Generated with Claude Code

@jasonstantler Rechecked on 18a777b. Server tests (764), client tests (1031), check:i18n and the build pass.

1 (a Stack made live breaks the page) is fixed. In Edge, holding Photos on Chores makes the Stack with no "Maximum update depth" errors, and none come later. The Stack stays one card wide, nothing is left floating, and dragging it onto a new tab in the dock moves it with both widgets (their settings kept, still marked in_stack). My full run passes 22 of 22, up from 18.

2 (the display-mode Home Assistant routes) is unchanged, so that's what's left before merge:

• POST /api/devices/<any>/modes/ha/helper with { "entity_id": "input_select.<anything>" } still runs set_options on that helper with no PIN, and still makes a device row for a name that doesn't exist.
• PATCH /api/devices/<name>/settings still accepts displayModes.ha.helper / helperId from the client, after which /modes/ha/sync and /modes/ha/select write to that helper.

The fix suggested last time still fits: keep the stored displayModes.ha when the settings PATCH arrives, check the admin PIN on /modes/ha/helper (as /api/plugin/v1/ha/:pluginId/action does: checkAdminPin unless the display remembers it), and return 404 for an unknown device. Once that's in, I'll recheck and merge.

🤖 Generated with Claude Code